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ABSTRACT 



A security architecture has been developed in which a single 
sign-on is provided. Session credentials are used to maintain 
continuity of a persistent session across multiple accesses to 
one or more information resources, and in some 
embodiments, across credential level changes. Session cre- 
dentials are secured, e.g., as a cryptographically secured 
session token, such that they may be inspected by a wide 
variety of entities or applications to verify an authenticated 
trust level, yet may not be prepared or altered except by a 
trusted authentication service. Some embodiments of the 
present invention associate trust level requirements with 
information resources. Authentication schemes (e.g., those 
based on passwords, certificates, biometric techniques, 
smart cards, etc.) are associated with trust levels, and in 
some embodiments, with environmental parameters. For 
example, in one configuration, a login service obtains login 
credentials for an entity commensurate with the trust level 
requirement(s) of an information resource (or information 
resources) to be accessed and with environment parameters 
that affect the sufficiency of a given credential type. Once 
login credentials have been obtained for an entity and have 
been authenticated to a given trust level, session credentials 
are issued and access is granted to information resources for 
which the trust level is sufficient. Advantageously, by using 
the session credentials access is granted without the need for 
further login credentials and authentication. In some 
configurations, session credentials evidencing an insufficient 
trust level may be remedied by a session continuity preserv- 
ing upgrade of login credential. 

32 Claims, 7 Drawing Sheets 
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ACCESS MANAGEMENT SYSTEM AND 
METHOD EMPLOYING SECURE 
CREDENTIALS 

BACKGROUND 

1. Field of the Invention 

The invention relates to information security, and more 
particularly, to systems and method for improving the secu- 
rity of information transactions over networks. 

2. Description of the Related Art 

The internet has become an important medium for infor- 
mation services and electronic commerce. As the internet 
has been commercialized, organizations initially established 
their presence in cyberspace by making information 
(typically static, non-sensitive promotional information) 
available on resources well removed from the operational 
infrastructure of the organization. Security issues were often 
addressed by isolating publicly accessible resources (e.g., 
web servers) from more sensitive assets using firewall 
techniques. As long as the publicly accessible information 
and resources were relatively non-sensitive and user inter- 
actions with such information and resources was not mission 
critical, relatively simple firewall techniques were adequate. 
Though information and resources outside the firewall were 
at risk, the risk could generally be limited to non-proprietary 
information that was easily replaceable if compromised. 
Proprietary information and systems critical to day-to-day 
operations were sheltered behind the firewall and informa- 
tion flows across the firewall were filtered to exclude all but 
the comparatively non -threatening services such as elec- 
tronic mail. 

However, as the internet has become more pervasive, and 
\ as the sophistication of tools and techniques has increased, 

! several aspects of the security environment have changed 

dramatically. First, businesses have recognized the power of 
information transactions that more tightly couple to opera- 
tional data systems, such as order processing, inventory, 
payment systems, etc. Such transactions include electronic 
commerce with direct purchasers or consumers (e.g., 
browsing, selecting and purchasing of books by members of 
the public from an on-line bookseller) as well as supply 
chain and/or business partner interactions (e.g., automated 
just-in-time inventory management, customer-specific 
pricing, availability and order status information, etc.). 
Commercially relevant transactions increasingly require 
information flows to and from secure operational systems. 
Second, even in formation- only services are increasingly 
mission-critical to their providers. Corporate image can be 
adversely affected by unavailability of, or degradation 
access to, otherwise non -sensitive information such as cus- 
tomer support information, product upgrades, or marketing 
and product information. Because many businesses rely 
heavily on such facilities, both unauthorized modification 
and denial of service represent an increasing threat. 

Individual information service or transaction system typi- 
cally exhibit differing security requirements. While it is 
possible to field individualized security solutions for each 
information service or transaction system, - individualized 
solutions make it difficult to maintain a uniform security 
policy across a set of applications or resources. Furthermore, 
individualized solutions tend to foster incompatible security 
islands within what would ideally be presented to consumers 
or business partners as a single, integrated enterprise. For 
example, a user that has already been authenticated for 
access to an order processing system may unnecessarily be 
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re -authenticated when accessing an order status system. 
Worse still, a set of individualized solutions is typically only 
as good as the weakest solution. A weak solution may allow 
an enterprise to be compromised through a low security 

5 entry point. 

Another problem with individualized solutions is a veri- 
table explosion in the number of access controls confronting 
a user. As more and more business is conducted using 
computer systems, users are confronted with multiple iden- 

10 tifiers and passwords for various systems, resources or levels 
of access. Administrators are faced with the huge problem of 
issuing, tracking and revoking the identifiers associated with 
their users. As the "user" community grows to include 
vendors, customers, potential customers, consultants and 
others in addition to employees, a huge "id explosion" faces 

15 administrators. Furthermore, as individual users are them- 
selves confronted with large numbers of identifiers and 
passwords, adherence to organizational security policies 
such as password restrictions and requirements (e.g., length, 
character and/or case complexity, robustness to dictionary or 

20 easily- ascertainable information attack, frequency of update, 
etc.) may be reduced. As users acquire more passwords — 
some individuals may have 50 or more — they cannot help 
but write down or create easy-to -remember, and easy-to- 
compromise, passwords. 

25 SUMMARY 

Accordingly, a security architecture has been developed 
in which a single sign -on is provided. Session credentials are 
used to maintain continuity of a persistent session across 

30 multiple accesses to one or more information resources, and 
in some embodiments, across credential level changes. Ses- 
sion credentials are secured, e.g., as a cryptographic ally 
secured session token, such that they may be inspected by a 
wide variety of entities or applications to verify an authen- 

35 ticated trust level, yet may not be prepared or altered except 
by a trusted authentication service. Some embodiments of 
the present invention associate trust level requirements with 
information resources. Authentication schemes (e.g., those 
based on passwords, certificates, biometric techniques, 

40 smart cards, etc.) are associated with trust levels, and in 
some embodiments, with environmental parameters. For 
example, in one configuration, a login service obtains login 
credentials for an entity commensurate with the trust level 
requirement(s) of an information resource (or information 

45 resources) to be accessed and with environment parameters 
that affect the sufficiency of a given credential type. Once 
login credentials have been obtained for an entity and have 
been authenticated to a given trust level, session credentials 
are issued and access is granted to information resources for 

50 which the trust level is sufficient. Advantageously, by using 
the session credentials access is granted without the need for 
further login credentials and authentication. In some 
configurations, session credentials evidencing an insufficient 
trust level may be remedied by a session continuity preserv- 

55 ing upgrade of login credential. 

In one embodiment in accordance with the present 
invention, a session credential includes a principal identifier 
uniquely identifying a principal and an encoding of autho- 
rization accorded by the security architecture after prior 

60 authentication of a login credential corresponding to the 
principal. The principal identifier and authorization encod- 
ing are cryptographically secured and allow the security 
architecture to evaluate sufficiency of the authorization for 
access to the one or more information resources without 

65 re -authentication of the login credentials. In one variation, 
the session credential is supplied external to the security 
architecture as a session token. 
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In another embodiment in accordance with the present Therefore, to aid persons of ordinary skill in the art in 

invention, a session token is provided for transfer between understanding the full scope of the invention, some of that 

a client entity operating on behalf of a principal and a terminology is now defined, 
security architecture controlling access to an information 

resource. The session token includes a principal identifier 5 Glossary 
uniquely identifying the principal and an indication of 

authorization level accorded by the security architecture Access Management: Systems, methods and techniques 

after prior authentication of a login credential corresponding for controlling use of information resources. Typically, 

to the principal. The principal identifier and authorization access management systems employ both authentication and 

level indication are cryptographically secured and allow the authorization to control access to information resources, 

security architecture to evaluate sufficiency of the authori- Authentication: A process used to verify the identity of an 

zation for access to the information resource without entily> M typically implemented, an authentication method 

re-authentication of the login credentials. fe employed t0 verif y the identity of a ^ or object based 

In still another embodiment in accordance with the on a cre dential supplied by the user or object, 

present invention, a method of providing authorization veri- * * * . . - . . , . 

fication in a security architecture controlling access to one or 15 Authorization: A process for determining whether an 

more information resources includes obtaining a login ere- ldentlt ? 15 V^rmMed to perform some action, such as access- 

dential and authenticating a principal thereby and issuing a m S a resource - Typically, an identity will be authenticated, 

cryptographically secured session credential. The crypto- though in some configurations certain identities need not be. 

graphically secured session credential encodes at least an Credential: Evidence: of identity used to authenticate an 

identifier for the principal and a first authorization accorded 20 entity. Exemplary credentials types include passwords, cer- 

based on the authenticating. For plural requests for accesses tificates or other encrypted indicia based on asymmetric, 

to the one or more of the information resources, the method symmetric, public, private, or secret key technologies, one- 

further includes selectively allowing access based on suffi- time passwords, biometric indicia such as by retinal scan, 

ciency of the first authorization encoded by the crypto- voice print, finger print, etc., and possession based indicia 

graphically secured session credential for access to the one 2 5 such as smart cards, Enigma cards, keys, etc. In some 

or -more of the information resources, wherein the selective realizations, credentials may be associated with users, 

allowing is performed without additional logm credential sessions> functional objects, etc. 

authenticating. ^. . ■ „. . 

In still yet another embodiment in accordance with the Dl S ltal Signature: A transformation of a message using an 

present invention, an information access control facility 30 asymmetric cryptosystem such that a person having the 

includes an application proxy and means responsive to the initial message and the signer s public key can accurately 

application proxy. The application proxy is for receiving an determine whether the transformation was created using the 

access request targeting one of the information resources, private key that corresponds to the signer's public key and 

extracting a cryptographically secured session token from whether the message has been altered since the transforma- 

the access request, and selectively proxying the access tion was made. 

request. The means responsive to the application proxy is for 35 Entity: A user or object, including data objects and/or 

evaluating sufficiency of an authorization encoded in the functional objects such as applications, components, 

cryptographically secured session token for access to the modules, services, processes, threads, etc., as well as instan- 

targeted information resource. tiations mereof In configurations, only user entities 

BRIEF DESCRIPTION OF THE DRAWINGS 4Q (typically, the human principal interacting with a software 

The present invention may be better understood, and its program or on whose behalf a software agent purports to act) 

numerous objects, features, and advantages made apparent are considered. In other configurations, entities include 

to those skilled in the art by referencing the accompanying functional objects without an associated human principal, 

drawings. Tk e identity of an entity may be authenticated using a 

FIG. 1 is a block diagram illustrating information flows 45 cre dential. 

between components in a security architecture employing Session: A period and collection of states spanning one or 

secure session credentials in accordance with an exemplary more interactions between an entity and an information 

embodiment of the present invention. environment. As used herein a session may span multiple 

FIG. 2 is a flow chart illustrating operation of a security interactions with multiple resources of the information envi- 

architecture employing secure session credentials in accor- 50 ronment and, in some configurations, may span multiple 

dance with an exemplary embodiment of the present inven- information access protocols (e.g., HTTP, FTP, telnet, etc.). 

tion. A session has a beginning and an end. During its existence, 

FIG. 3 illustrates interactions between functional compo- a session has state " M ^ berein ' the term sessioD connotes 

nents in a functional decomposition of a security architec- a S reater Persistence than as sometimes used to describe the 

ture employing secure session credentials in accordance 55 period of a "session layer" protocol interaction, which in the 

with an exemplary embodiment of the present invention. case of 501116 protocols, such as HTTP, is generally very 

FIG. 4 illustrates relations between login credentials, short-lived, 

session credentials and a cookie encoding of a session token si le Si Security Architecture 
in accordance with an exemplary embodiment of the present 

invention. 60 FIG. 1 provides an overview of major interactions 

The use of the same reference symbols in different draw- between components for an exemplary security architecture 

ings indicates similar or identical items. in accordance with the present invention. As illustrated in 

FIG. 1, a client application, e.g., a browser 170 operated by 
DESCRIPTION OF THE PREFERRED a ^teracts with the security architecture via a gate- 
EMBODIMENT(S) 65 keeper and entry handler component HO and a login corn- 
Some terminology used in this specification has meaning ponent 120. Gatekeeper and entry handler component 110 
particular to the context of embodiments described herein. provides an entry point for external client applications 
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requesting access to enterprise applications and/or resources tool configuration, a desired security policy may dictate that 

190, including e.g., information resources 191, 192 ... 193, a salary tool is accessible only from with a company's 

for which access management is provided by the security internal network. No level of authenticated trust may be 

architecture. Using facilities provided by a session manage- sufficient to access such a tool from outside company 

ment component 160, an authorization component 140, an 5 network. To facilitate implementation of such a security 

authentication component 130, an identification component policy, authorization component 140 could refuse access 

150, and login component 120, the gatekeeper/entry handler based on environment parameters indicating a session origi- 

component 110 allows, redirects or refuses access requests nating outside the company's internal network, 

in accordance with a security policy. Of note, in certain embodiments in accordance with the 

Individual information resources typically have differing 10 present invention, the mapping of login credential types and 

security requirements. In addition, individual types of access authentication mechanisms to trust levels is influenced by 

to a single information resource may have differing security environment information such as time of request, source of 

requirements. Nonetheless, a given level of security may be request, connection speed, and/or client application (e.g., 

sufficient for more than one of the information services or browser) environment information. In this way, even with a 

access types. For example, information resource 191 may 15 Sta * c **} of m *W™Z rules, the set of credential types and 

include a product information service for providing general f ^hentication mechanisms suitable to support a given trust 

. r 4 . . j * j - *- j * u * * l eve I mav var V based on environment information. In 

information such as product descriptions or data sheets to i • i j j • uj ■ j 

iL L1 . t_-i • c *■ f r\/y • i j •. general, mapping rule dependencies are based on perceived 

the public, while information resource 192 includes an order ° . . r \,° *i S 

v . _ _ T . variations in threat characteristics and/or requesting entity 

processing system for an eCommerce site Information capabilitics . In ^ embodiments in accordance with the 

resource 193 may include functions for supply chain inter- 20 present mventioa) ga tekeeper/entry handler component 110 

actions such as access to inventory information or current fa the authority on environment information for a particular 

selling price information. Both the product information requesting entity. 

service and order intake functions of the eCommerce may Iq some embodiments, mapping rules may be dynami- 

operate with similar security requirements, e.g., allowing ca ii y varied. For example, if a particular login credential 

access by minimally authenticated, non-hostile entities. On 2 s type and/or authentication method is deemed insecure (e.g., 

the other hand, supply chain functions may require a higher because compromised or because of a changing threat 

level of security. Order status functions of the order pro- profile), the trust level mappings can be updated and have 

cessing system may require a mid -level of security. enterprise- wide effect. In addition, several other advantages 

Login component 120, operating in conjunction with are achieved by defining the authentication requirement 

gatekeeper/entry handler component 110 and other compo- 30 interface between enterprise applications and/or resources 

nents of the security architecture, provides a single sign-on and the security architecture in terms of required trust levels, 

interface for access to enterprise applications and/or rather than in terms of particular credential types and 

resources 190. In an exemplary embodiment, security authentication methods. First, single sign -on configurations 

requirements are expressed in terms of trust levels and login are facilitated using an enterprise-wide credential obtaining, 

component 120 obtains login credentials for an entity 35 authentication and session tracking infrastructure. Second, 

requesting access to one of the enterprise applications and/or authentication requirements may be enforced uniformly in 

resources 190. The login credentials obtained are selected accordance with an enterprise-wide security policy and with 

from a set of credential types that, if authenticated, are reduced vulnerability to a lax security implementation by 

sufficient to achieve the trust level requirement of an appli- any particular information resource. Third, credential types 

cation or information resource to be accessed. Without 40 ana< authentication methods can be added, deleted, or 

limitation, typical login credential types and associated mapped to a new trust level, all without modification of 

authentication mechanisms include those based on enterprise applications and resources. Of course, all advan- 

passwords, certificates, biometric techniques, smart cards, tages need not be achieved in any particular implementation, 

etc. Other credential types and associated authentication In certain embodiments in accordance with the present 

mechanisms are described elsewhere herein. 45 invention, a credential upgrade facility is provided. In 

In some embodiments in accordance with the present response to an access request from an entity for which login 

invention, gatekeeper/entry handler component 110 queries credentials have already been obtained and authenticated, 

authorization component 140 to obtain authorization for but for which the obtained and authenticated log in creden- 

access to a particular requested enterprise application or tials are insufficient for the trust level associated with the 

information resource by the requesting entity (e.g., the 50 requested access, authorization component 140 may indicate 

browser user). If the entity requesting access has not yet that the access request is to be redirected to login component 

been authenticated to the trust level required for the par- 120 so that sufficient login credentials may be obtained and 

ticular access to the particular enterprise application or authenticated to the required trust level. Of note, credential 

information resource requested, authorization component upgrade facilities in accordance with certain embodiments 

140 may indicate that the access request is to be redirected 55 of the present invention allow upgrade without loss of 

to login component 120 so that login credentials may be session continuity. 

obtained and authenticated to a particular trust level. If, on In addition to the obtained login credentials, some con- 

the other hand, login credentials have already been obtained figurations in accordance with the present invention employ 

for the requesting entity and the requesting entity has been session credentials as a mechanism for evidencing prior 

authenticated using the obtained credentials such that the 60 authentication of obtained login credentials and for binding 

required trust level has been achieved, the access will individual transactions to a particular session. In some 

typically be allowed without the need for further login configurations, session credentials are also employed in a 

credentials and authentication. In certain circumstances, session token form advantageous for transactions external to 

authorization component 140 may indicate that the access is the security architecture. In an exemplary realization, ses- 

to be refused. For example, authorization component 140 65 sion tokens are encoded for supply to browsers as cookies, 

may be programmed to perform more stringent testing FIG. 4 illustrates relationships between exemplary login 

beyond a trust level requirement. In an exemplary enterprise credential, session credential and session token objects. 
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As described above, login credentials (e.g., represented in the session credential to be read by anyone and changed by 

a form such as exemplary login credentials structure 410) no one. For some configurations, the implementation of FIG. 

are obtained for a client entity. Typically, login credentials 4 is preferred because encrypted portion 421 can be used as 

encoded in login credentials structure 410 are obtained from an externally supplied session token. Such a session token 

a principal via browser client and serve as evidence that the 5 representation is a compact representation of the session 

principal (e.g., a human user) is entitled to a particular credential particularly appropriate for encoding as a cookie 

identity. Accordingly, login credentials structure 410 placed at a browser and returned with subsequent access 

encodes a userld and a domainld within which the userld requests. 

should uniquely correspond to a principal. Specific login Referring again to session credentials structure 420, a 

credentials, e.g., a password, a certificate, results of a 10 session id, a principal id, a trust level, group ids, a creation 

biometric process, a response to an Enigma challenge or time and an expiration time are encoded in both in encrypted 

results of a smart card interrogation, etc. are encoded in portion 421 and clear text portion 422. The session id is a 

login credentials structure 410, as a tagged value. An authen- unique identifier for a persistent session maintained by the 

ticationScheme is specified and creation time may be security architecture .1 n implementations in which credential 

encoded to limit replay attacks. In the implementation of ^ upgrade is provided or in which a session credential expi- 

FIG. 4, login credentials structure 410 is encrypted using the ration and refresh is provided, multiple successively issued 

public key of an authentication service (e.g., of authentica- session credential instances may encode the same session id 

tion component 130). Because the key is public, any and correspond to the same persistent session. Principal id 

component, even untrusted components may encrypt login encodes an identifier for a principal to which the security 

credentials for provision to authentication component 130, 2 o architecture has resolved login credentials. For example, a 

while only authentication component can decrypt the login credential including a username jdoe and a password 

encrypted login credentials using its private key. In some corresponding to jdoe may be resolved by the security 

configurations, secure transfer protocols, e.g., SSL, are architecture to a unique principal id associated with John. Q. 

employed to secure login credentials between a client entity Doe of the shipping and receiving department, having an 

such as browser 170 and the security architecture while 2 5 employee badge number of 12345, etc. 

encryption with a public key of an authentication service is In some embodiments, a trust level encodes the authori- 

performed within the security architecture, e.g., at login zation level to which a principal has been authenticated. In 

component 120. In other configurations, encryption with a such embodiments, the encoded trust level serves as a basis 

public key of an authentication service may be performed at for evaluating whether a principal associated with the ses- 

the client entity. 30 sion credentials has been authenticated to a sufficient level 

If the encrypted login credentials provided to an authen- for access to a requested resource. For example, a trust level 

tication service are determined to be authentic, session of 5 may be sufficient for access to information resources 

credentials are issued. In the implementation of FIG. 4, having a trust level requirement of 5 or less. Trust levels 

session credentials are embodied in a form such as exem- offer an attractive decoupling of authorization levels and 

plary session credentials structure 420. Encrypted and clear 35 authentication methods as described elsewhere herein, 

text portions (421 and 422) of session credentials structure However, in some embodiments, an authorization encoding 

420 allow contents of the session credential to be read by may establish that a principal has been authenticated using 

anyone and changed by no one (except the authentication a particular authentication mechanism. In either case, an 

service possessing a private key). Contents of encrypted authorization (e.g., encoded as a trust level) in a crypto- 

portion 421 correspond to that clear text portion 422 but are 40 graphically secured session credential allows the security 

encrypted using the private key of the authentication service architecture to authorize accesses based on prior authenti- 

(e.g., of authentication component 130). Of note, principal cation of a login credential and without involvement of the 

ids, authorizations and other contents encoded in the session authentication service. 

credential may be read by components of the security Group ids can be used to grant or limit authorization scope 
architecture, and in some embodiments by components 45 based on group membership. Typically, session credentials 
external to the security architecture. Such components can serve as evidence of prior authentication and authorization 
verify the authenticity of information stored in clear text for multiple accesses to information resources controlled by 
portion 422 using encrypted portion 421 and a public key the security architecture. However, session credentials may 
corresponding to the private key of the authentication ser- be replaced on a login credential upgrade as described 
vice. Of note, the information contained in a session ere- 50 elsewhere herein. In addition, session credentials of limited 
dential is generally not sensitive. What is sensitive is the temporal validity may be refreshed by periodic replacement, 
state of the information. Therefore, security architectures In the configuration of session credentials structure 420, 
employing facilities described herein ensure that informa- creation time and expiration time allow the security archi- 
tion contained in the session credential is provably constant tecture to improve resistance to replay attacks. Session 
once set by an authentication service. By using the public 55 credentials typically have a relatively short expiration time 
key of the authentication service, which will in general be (e.g., 15 minutes from creation or less) and underlying login 
freely available, together with the encrypted information, credentials will be reauthenticated prior to expiration of the 
any application can read the information (e.g., in free text) session credential. Assuming that the underlying login 
and ascertain that the session credential was created by the credentials, which are stored under the public key of authen- 
authentication service and that the session credential has not 60 tication component 130, remain valid, authentication corn- 
been tampered with. Assuming that the authentication ser- ponent 130 will issue a replacement cryptographically 
vice's private key has not been compromised, tampering secured session credential (e.g., as session credentials struc- 
with the session credential will result in a decryption failure. ture 420). Depending on then current trust level mappings 
In an alternative implementation (not shown), session and, in some configurations, depending on then current 
credentials may be digitally signed and verified by a public 65 environment parameters, the authorization accorded by the 
key corresponding to a private key. In such an alternative security architecture and encoded as a trust level may differ 
implementation, the digital signature also allows contents of from that encoded in the session credential replaced. If a 
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principal id or login credential has been revoked, reauthen- connections, environment information such as line speed 

tication may fail and a user may be prompted to supply a and low-level line encryption are ascertained. Additional 

sufficient login credentials as described elsewhere herein. information, such as source number (e.g., from caller id 

Session id and principal id will typically remain the same for information or based on a callback configuration), signaling 

successive session credentials associated with a single per- 5 type ( e -g-> POTS or digital ISDN), etc., may also be 

sistent session. obtained. For network connections, similar environment 

* , , , i . c t , . information (e.g., source network and/or node, Virtual Pri- 

As previously described, one advantage of the approach t XT ^ , 7*Vnxi\ i i ■ \ \ L 

employed in session credentials structure 420 Is that ^Network (VPN) low-level encryption, etcO may be 

iu» ij ♦ obtained from incoming requests themselves or based on a 

encrypted portion 421 may also be employed as a compact ... . ■ */ *• i . .\ »# 

• ,i t / am f • j 4 - i f m particular entry point (e.g., a particular router or port). More 

session token representation 430 ot session credential for 10 r « 4 , ) f . « 5< A L • 

, . , t_ j. j . iL generally, gatekeeper/entry handler component 110 obtains 

use as a cookie. In one embodiment in accordance with FIG. ° 3 r . f- . , r , . 

^ * j vin • * * * and/or maintains information such as connect location (if 

4, encrypted portion 421 is a string encoded representation t . . . x , . . „ 4 . . . v , 

r • .i u * i_ l i j . ascertainable), temporal information such as request time/ 

ot approximately 200 characters which may be placed at a , t • . ^ *■ . / r t_i • t_ L t_ 

. / . , r e ~>y c^iU i\ ■ . date, session start time/date, etc. (preferably in both the 

browser (e.g., via transfer 5, 23 or 23 A ot FIG. 1) using a set T . \ ... , c c c j # . ' . 

i . . • /. i« client entity s frame of reference and the security architec- 

cookie directive, 1S _ . j ■ r , J e 

ture or requested mformation resource s frame of reference, 

Exemplary Configuration tf location fe ascertainable), and client type and/or capabili- 
ties (e.g., browser type and Java Development Kit (JDK) 

Referring to FIG. 1, an entity (e.g., a browser 170 level). In some configurations, information on line speed, 
operated by a user) interacts with enterprise applications 2Q origination point (e.g., inside or outside of a corporate 
and/or resources 190 and the security architecture via a network), browser type, encryption capability, number of 
gatekeeper/entry handler component 110 and a login com- hops, latency, system type, etc. may be gathered. Such 
ponent 120. In general, a wide variety of entities, including information is used in some configurations for mapping 
human users operating browser and/or non-browser client particular authentication mechanisms to trust levels and for 
applications as well as automated agents and systems, may 2$ authorization decisions. Environment information is gener- 
interact with enterprise applications and/or resources 190 ally packaged into a data structure that is associated with a 
and the security architecture as described herein. client session. Other components of the security architecture 
Furthermore, a variety of information resource identification may add additional client environment information, such as 
schemes, such as by Uniform Resource Locator (URL), authentication strength or current trust level, 
resource address, identifier or namespace designation, may 3Q Gatekeeper functionality (e.g., in gatekeeper/entry han- 
be employed. However, for purposes of illustration and not dler component 110) checks whether a session is already 
limitation, an exemplary interaction involving a browser and associated with the incoming request. Although other tech- 
information resources identified by URL is described in niques are possible, in some configurations in accordance 
detail. Nonetheless, based on the description herein, persons with the present invention, gatekeeper/entry handler com- 
of ordinary skill in the art will appreciate a wide variety of 35 ponent 110 checks for the presence of a session token in the 
configurations in accordance with the present invention in incoming request. Use of session tokens is described in 
which non -browser clients, automated agents or other sys- greater detail below; however, in short, a session token may 
terns interact with enterprise applications and/or resources be, any data supplied to the client entity for use in uniquely 
190 and the security architecture using any of a variety of identifying an associated session. In general, preferred ses- 
information resource identification schemes. 40 s ion token implementations are cryptographically secured 

Focusing then on an exemplary browser-type client entity, and include facilities, such as expiration or mapping to a 

browser 170 requests access to one or more of enterprise particular connection, to limit risk of replay attack and/or 

applications and/or resources 190 (e.g., information resource spoofing. Some session token implementations may encode 

191) by presenting an URL to gatekeeper/entry handler session, principal, and/or trust level information. Some 

component 110, which acts as a point of entry for client 45 session token implementations may employ cookies, URL 

entities requesting access to applications and/or resources encoding, or other similar techniques for binding to incom- 

controlled by the security architecture. Gatekeeper/entry ing requests. 

handler component 110 receives the request as a proxy for In some configurations, session tokens are employed to 

the requested resource. In some configurations, a combined facilitate session continuity and to allow the security archi- 

gatekeeper/entry handler instance is provided, while in 50 tecture to associate prior authentication of login credentials 

others, separate and/or multiple instances are provided with with an incoming access request. In one utilization, session 

functionally identical interfaces to other components of the tokens are issued to client entities as part of an interaction 

security architecture. In some configurations, multiple with the security architecture and are thereafter presented 

instances of entry handler functionality (e.g., interception of with access requests. In some configurations, new session 

inbound requests and collection of environment 55 tokens (each corresponding to a single session) are issued to 

information) are provided. For example, one or more client entity on each credential level change. In other 

instances for each of several connection types (e.g., dialup, configurations, a session token may remain the same even as 

WAN, etc.) may be employed. One or more instances of credential levels are changed. Session continuity means the 

gatekeeper functionality (e.g., allowing access for autho- maintenance of coherent session state across one or more 

rized requests and otherwise denying or initiating appropri- 60 interactions between an entity and an information environ - 

ate responsive action) may also be provided. Configurations ment. 

and functional decompositions suitable to a particular envi- Components of session state (e.g., in some configurations, 
ronment and expected load requirements will be appreciated principal id, session id, authenticated trust level, group ids 
by persons of ordinary skill in the art. and/or roles, creation time, expiration time, etc.) are main- 
Entry handler functionality (e.g., in gatekeeper/entry han- 65 tained or advanced throughout the duration of a session, 
dler component 110) ascertains much of the requesting Typically, aspects of session state are represented internally 
client's environment information. For example, for dial-up by the security architecture and a session token (e.g., a 
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session id encoded in a cryptographically secured session 
token) allows the security architecture to reference into the 
internal representation. However, in some configurations, at 
least some aspects of session state may be represented or 
duplicated in the session token. For example, a principal id 
and current trust level are encoded in one realization of a 
cryptographically secured session credential and associated 
session token or cookie. In general, a variety of facilities, 
such as cookies, can be used to maintain state across a series 
of protocol interactions, such as HTTP transactions, that do 
not otherwise support persistent session state. 

Referring again to FIG. 1, if a session token is present in 
the incoming request, gatekeeper/entry handler component 
110 resolves the token to a session object. Alternatively, if no 
session token is present or if a session token is invalid, 
gatekeeper/entry handler component 110 establishes a new 
session (2). In an exemplary configuration in accordance 
with FIG. 1, session management component 160 allocates 
a new session and supplies associated default session cre- 
dentials (2) based on the requested information resource and 
environment information. Note that a session is created 
irrespective of authentication status or identity, although 
some implementations may refuse to even allocate a session 
based on particular information resource requests and/or 
environment information. Given a session object, which 
may be resolved from a received session token or newly 
allocated, gatekeeper/entry handler component 110 interacts 
(3, 4) with authorization component 140 to determine 
whether the requested access is authorized. For some 
requested accesses and security policies (e.g., anonymous 
ftp access to certain archives), even a session without 
authenticated login credentials (trust level=0) may be autho- 
rized. For others, a more substantial trust level may be 
required. 

Gatekeeper/entry handler component 110 supplies autho- 
rization component 140 with an identifier for the requested 
resource (e.g., the requested URL) and an identifier for the 
associated session. Preferably, the associated session iden- 
tifier is cryptographically secured (e.g., as a signed session 
credential). In some configurations, the signed session cre- 
dential is obtained from the corresponding session object. In 
the case of a pre-existing session, the signed session cre- 
dential may be obtained using a received session token. In 
any case, authorization component 140 receives (3) the 
requested resource and session identifiers and responds (4) 
in accordance with the trust level requirement of the 
requested resource. In configurations for which sensitivity to 
a changing environment is desired, environment information 
may also be supplied to authorization component 140. In an 
exemplary configuration, authorization component 140 
responds with an ALLOW, REDIRECT, or REFUSE 
response based on the sufficiency of a current trust level. In 
some configurations, authorization component 140 dynami- 
cally calculates a current trust level based on the signed 
session credentials and environment information. In others, 
authorization component 140 may base its ALLOW, 
REDIRECT, or REFUSE response on a "current" trust level 
previously associated with the signed session credentials: 
Generally, an access request with sufficient current trust 
level is ALLOWED and forwarded (14) without further 
authentication. An authorization request without proper 
parameters (e.g., without a specified information resource or 
without a properly secured session credential) may be 
REFUSED. Authorization requests associated with a client 
entity that has been blacklisted or for a resource for which 
the associated client entity cannot be authenticated using any 
available method to achieve the required trust level may also 



>8,322 Bl 

12 

be REFUSED. For example, a given security policy and 
associated trust level mappings may dictate a REFUSE 
response in response to an access request to a sensitive 
resource (such as financial data) by any client entity (even a 
5 browser supplying the,digital certificate for the CFO, and 
therefore presumably operating on behalf of the CEO) if the 
access request is received over a dial-up line and originates 
from an unknown number or is received outside of working 
hours. 

10 In general, there is an implicit, base level of environment 
inherent in an authenticated trust level; however, in some 
configurations, a particular authorization transaction may 
dig deeper into environment information before responding. 
For example, in configurations providing log-up 
capabilities, an authorization service will typically redirect 

15 to a login service if the trust level associated with current 
session credentials is insufficient for a requested access. 
However, for sensitive applications in such a configuration, 
an inadequate trust level may result in a REFUSED message 
rather than a log-up REDIRECT depending on the particular 

20 security policy implemented. 

A REDIRECT response is used to forward the access 
request to login component 120 so that sufficient login 
credentials may be obtained and authenticated to achieve the 
required trust level for the requested access. Note that in 

25 some configurations, both initial login credentialing and 
credential upgrade are provided using the REDIRECT facil- 
ity. In response to a REDIRECT response (4), gatekeeper/ 
entry handler component 110 redirects (5) browser 170 to 
login component 120. In one configuration, gatekeeper/entry 

30 handler component 110 issues a client-side redirect via 
HTTP location directive to forward the request to login 
component 120. Parameters such as required trust level, 
requested URL and credential passing method can be 
encoded in the redirect URL and supplied (6) by browser 

35 170 to login component 120. Alternatively, some parameters 
can be passed (5 A) directly (e.g., through a HttpSession 
object) although a stateless configuration is preferred. 

A session token is passed to browser 170 in conjunction 
with the redirect (5) to login component 120. Based on the 

40 description herein, persons of ordinary skill in the art will 
appreciate a number of suitable mechanisms for passing the 
session token, including those based on cookies and URL 
encoding. Preferably, mechanisms employed are based on 
facilities provided by commercially available browsers (e.g., 

45 in accordance with HTML 3.x, 4.x or other de-facto 
standards), although customized or plug-in facilities for 
receiving and supplying session token may be employed. In 
one suitable configuration, the session token is cryptographi- 
cally secured and encoded in a cookie placed at browser 170 

50 using a set cookie directive embedded in the redirect. Other 
configurations may use a less persistent session identifica- 
tion method, such as passing an identifier or session token in 
the redirect URL without storage at browser 170. Still other 
configurations may transmit a session token, a session 

55 credential, or identifier such as a session handle for storage 
in a medium such as a smart card. In configurations provid- 
ing credential upgrade, persistent session identification 
methods are generally preferred, even for a not yet authen- 
ticated client entity, for consistency of approach. Note that 

60 although the identity of the client entity may not be authen- 
ticated to a sufficient level of trust, the redirected request 
includes a session token that at least identifies the session. 
Other configurations may omit the binding of session tokens 
to sessions of not yet authenticated client entities, though 

65 with some increase in complexity of login component 120. 
Browser 170 sends (6) login component 120 a new access 
request using the URL specified in the redirect from 
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gatekeeper/entry handler component 110. In configurations personal digital certificate (such as those issued by 

employing cookies as a medium far passing session tokens, Verisign™, Thwate, Entrust or other certificate authority) 

the new access request will include the cookie and therefore may be obtained from a browser 170 using an HTTP 

the session token. Note that in configurations in which the certificate request. Although credentials may be transacted 

security architecture controls access to resources in several 5 in a variety of ways, credentials are typically obtained from 

domains, care should be exercised to select a tag or tags for a user. Typically, the obtaining is indirect by asking the 

the cookie such that it will be provided through normal user's browser to complete the negotiation process. In such 

operation of the browser in subsequent accesses to any of the configurations, certificate-based authentication may be 

several domains. Persons of ordinary skill in the art will transparent to the user. In some configurations, further 

appreciate suitable tagging techniques, including the use of 10 authentication can be performed by using information 

multiple cookies. Login component 120 receives the access encoded within the certificate to query a certificate authority 

request and determines an appropriate authentication for current status or a lookup to an authentication database 

scheme based on mapping rules that identify those authen- may be performed for more detailed requirements. In an 

tication schemes which are sufficient to achieve a given trust exemplary configuration, the more detailed information 

level. Preferably, the mapping rules are a function of envi- 35 could relate to session environment or could force an 

ronment information. In some configurations, mapping rules additional name/password authentication as part of the cer- 

are implemented as fuzzy sets wherein acceptable authen- tificate authentication chain. In a particular implementation 

tication schemes are a function of required trust level and such facilities can be provided by mapping rule encodings 

environment information. In this way, environment affects that require successful authentication using multiple authen- 

the set of authentication schemes sufficient to meet a trust 20 tication methods to achieve a given trust level, 

level requirement. Once login credentials have been obtained by login com- 

Generally, mapping rule logic is typically evaluated ponent 120, they are supplied (11) to gatekeeper/entry 

before a user is challenged to authenticate. Mapping occurs handler component 110 for authentication. In configurations 

as a function of session environment and particulars of the in which both gatekeeper/entry handler component 110 and 

information resource for which access is requested. By 2 5 login component 120 have access to a shared object such as 

evaluating the minimum trust level required by the target of the HttpSession object, login credential passing via the 

an access request, a service (e.g., a login service such as shared object is suitable. In other configurations, an HTTP 

provided by login component 120) derives a list of potential POST may be employed. In an exemplary configuration, the 

authentication methods. The service then checks current particular credential passing method is selected as part of the 

session environment against the allowed environment states 30 original HTTP redirect (e.g., encoded in the redirect URL) 

for each potential authentication method to trim the list although other configurations need not allow for a selection 

further. If there is no particular resource for which access is or may employ other facilities for selection of a credential 

being requested (e.g., if a user jumps straight to a sign-on passing method. 

page without requesting an access), the service will proceed Login component 120 also passes control of the access 

according to the lowest level of trust available consistent 35 request back to gatekeeper/entry handler component 110. In 

with session environment. Other configurations may employ an exemplary configuration, login component 120 issues a 

differing default behaviors. new HTTP request (11) specifying the originally requested 

In some configurations, login component 120 queries (7) URL, which has been stored in the HttpSession object. As 

authorization component 140 to identify the set of authen- before, gatekeeper/entry handler component 110 receives 

tication schemes that meet or exceed the required trust level 40 the request. Gatekeeper/entry handler component 110 

given a current environment. In other configurations, the extracts the login credentials from the request or from the 

mapping is performed by login component 120. In either HttpSession object and passes (12) the login credentials to 

case, login component 120 supplies (9) information to authentication component 130 for authentication. Authenti- 

browser 170 to allow the user to select from the suitable cation component 130 authenticates the login credential, and 

authentication schemes and to provide an associated login 45 if successful, queries (13) identification component 150 to 

credential. In some configurations, login component 120 establish a correspondence with a set of entity descriptors 

supplies browser 170 with a login page (e.g., HTML) that that uniquely identifies the requesting entity. In an exem- 

prompts the user for an application specific user ID and a plary configuration, entity descriptor types include: entity id, 

choice of authentication schemes. Interactions with browser system id (e.g., name/password), certificate, enigma id, 

170 depend on the set of credential types that, if 50 smartcard token, name/address, and phone. One or more of 

authenticated, would be sufficient to meet the trust level values may uniquely identify an entity and one or more 

requirement for access to the requested resource. For entity descriptor types may support multiple values (e.g., 

example, if more than one type of credential would be multiple digital certificates, name/password pairs, or phone 

sufficient, login component 120 may interactively allow a numbers per identity). Once the requesting entity has been 

user to select from amongst the credential types (e.g., using 55 identified (14), session parameters are updated (15) and 

any HTML-based dialog). Once a particular credential type session management component 160 supplies (16) session 

has been selected, login component 120 interacts with credentials. Preferably, session credentials are digitally - 

browser 170 to obtain an instance of the login credential to signed or otherwise cryptographically secured and returned 

establish the identity of the browser user. (17) to gatekeeper/entry handler component 110. 

Some credential types (e.g., useraame/password pairs, 60 Gatekeeper/entry handler component 110 again supplies 

onetime passwords, enigma challenge, etc) may be obtained (18) authorization component 140 with an identifier for the 

through an interactive process in which the user supplies the requested resource (e.g., the requested URL) and an iden- 

login credential(s) entry into an HTML form browser 170 ufier for the associated session (e.g., the signed session 

POSTs form contents back to login component 120. Others credentials, authorization component 140 responds with an 

(e.g., digital certificates) may be supplied (10) for the client 65 ALLOW, REDIRECT, or REFUSE response based on the 

entity from browser 170, or in some configurations, may be sufficiency the session credentials (and underlying authen- 

obtained from or via an agent or certificate authority. A tication of login credentials) for the trust level required for 
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the requested access. Login credentials should now be proxied (20) and results (21) are streamed directly (23A) 

sufficient for access to the requested resource and an back to browser 170. In some configurations, gatekeeper/ 

ALLOW response is supplied (19) by authorization compo- entry handler component 110 supplies an updated session 

nent 140. Gatekeeper/entry handler component 110 proxies token using a set cookie directive encoded with the results 

the requested access (20, 21) to information resource 191 5 streamed (23 A) back to browser 170. An updated session 

and streams (22) results back to login component 120. Login token, if supplied, resolves to the same session object as the 

component 120, in turn, streams (23) results back to browser session token replaced. For example, in some 

170. configurations, both session tokens encode a same session 

In some embodiments in accordance with the present handle, although other aspects associated with session token 

invention, session continuity is facilitated by supplying a 10 security such as expiration may be updated. In other 

session token to browser 170. For example in one configurations, results (21) are streamed (23A) back to 

configuration, login component 120 supplies a session token browser 170 without an updated session token. In such 

using a set cookie directive encoded with the results configurations, the previously supplied session token 

streamed (23) back to browser 170. In response, browser remains valid until expired or otherwise invalidated. Some 

170 stores the cookie using a tag (typically a filename 15 variations may employ a session token refresh interval, 

encoding). Browser 170 supplies the cookie (and the session Depending on the information resource to which access is 

token) with subsequent access requests based on a corre- requested, previously obtained and authenticated login cre- 

spondence between the tag and the requested resource. dentials may be insufficient for the trust level requirement 

Typically, the correspondence is based on the second-level associated with requested access 1A. As before, authoriza- 

domain (e.g., sun.com) in which the requested resource is 2 o uon component 140 supplies gatekeeper/entry handler com- 

hosted, although nth-level domains or other resource iden- ponent 110 with an ALLOW, REDIRECT or REFUSE 

tification and session token associating schemes may be response based on the trust level accorded based on the 

employed. In configurations in which the security architec- previously obtained and authenticated login credentials and 

ture controls access to multiple domains across which a on the trust level requirement associated with requested 

spanning single sign -on is desired, multiple cookies may be 2 $ access 1A. Advantageously, authorization of individual 

employed. access requests is streamlined by the encoding of trust level 

Although the encoding of session tokens using cookies is in a cryptographically secured session credential or token. In 

presently preferred, in part because cookie facilities are the case of insufficient credentials, a REDIRECT response is 

widely supported and reasonably well accepted, other facili- supplied and gatekeeper/entry handler component 110 again 

ties may be employed to establish session continuity. For 30 redirects (5) browser 170 to login component 120. Addi- 

example, alternative URL encodings and/or custom or plug- tional login credentials are obtained as described above with 

in support for session identifier receipt, storage and supply reference to initial credentials. Upon successful 

may be employed. Also, some configurations may employ authentication, access request is proxied (20) and results 

lower-level session identifiers, e.g., as provided by a par- (21) are streamed (23A) back to browser 170. 

ticular connection type such as trusted caller id information 35 Preferably, gatekeeper/entry handler component 110 sup- 

or as associated with a low-level line encryption or virtual plies an updated session token using a set cookie directive 

private network infrastructure. As such facilities are likely to encoded with the results streamed (23A) back to browser 

be connection- type specific, it is envisioned that they may be 170. An updated session token, if supplied, resolves to the 

used in conjunction with other session identifier facilities same session object as the session token replaced. As a 

described above, e.g., session tokens encoded in cookies. In 40 result, session state (including e.g., identity mappings, 

one configuration, the unique Ethernet MAC address asso- authorizations, roles, permissions, environmental variables, 

ciated with a network interface card may be employed as a etc.) is maintained through the credential level change, 

session handle. The MAC address is then used to associate However, in the case of a credential upgrade, the session 

with a particular set of session credentials maintained by a object now encodes a login credential successfully authen- 

central authority. In general the representation of a session 45 ticated to achieve a higher trust level. In one advantageous 

handle can take may forms. configuration, the achieved (higher) trust level is encoded in 

Referring again to FIG. 1, subsequent access requests a cryptographically secured session token representation as 

(e.g., access request 1A) include a previously assigned a cookie streamed (23 A) back to browser 170 with results 

session token. As described above, gatekeeper/entry handler (21). 

component 110 uses the session token, if provided to resolve 50 FIG. 2 illustrates operation of an exemplary security 
a session object containing session credentials, and to deter- architecture providing a single sign-on facility with trust 
mine whether previously authenticated credentials are suf- level mapping to authentication requirements. As before, an 
ficient for the requested access. As described above, autho- access request is received (201) from a client entity. If the 
rization component 140 may be queried using session request does not contain a session identifier (e.g., a session 
credentials and an identifier for the requested resource to 55 key or token) or if the request can otherwise be reliably 
determine sufficiency of previously authenticated creden- associated with a session maintained by the security 
tials. In some configurations, sufficiency is determined using architecture, a new session is created (202). A trust level 
trust level mappings as described above. Depending on the requirement is determined for access to the requested 
information resource to which access is requested, and in resource in the context of the requesting session environ- 
some configurations depending on current session environ- 60 ment. In some configurations, as described above, the deter- 
ment information, access request 1A may or may not have mination is performed by an authorization service such as 
associated previously authenticated credentials sufficient to authorization component 140 Given a trust level 
support the requested access. In the case of an access request requirement, current session credentials are evaluated (203) 
1A having a trust level requirement commensurate with in the context of session environment information to deter- 
previously obtained and authenticated credentials (i.e., an 65 mine whether the previously supplied login credentials are 
access request for which no additional credentials need be sufficient to achieve the required trust level. In one advan- 
obtained via login component 120), the access request is tageous realization of session credentials and tokens, a 
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cryptographically secured encoding of trust level allows 
authorization to be confirmed without involvement of an 
authentication service (e.g., with reauthentication of login 
credentials). In the case of a newly created (202) session, the 
authorization evidenced by session credentials will typically 5 
be insufficient, although some security policies may allow 
anonymous access to certain resources. 

For a pre-existing session, i.e., for an access request that 
can be reliably associated with a persistent session by a 
cryptographically secured session token or otherwise, ses- 1Q 
sion credentials may or may not be sufficient for access to 
the currently requested resource. For example, after a first 
access, the identity of an entity accessing resources con- 
trolled by the security architecture will be authenticated to a 
trust level sufficient for that access. Depending on the trust 
level requirements of a subsequent access and, in some 15 
configurations, depending on then current trust level map- 
ping rules and environment information, the level of trust 
associated with a current session (e.g., as evidenced by 
current session credentials) may or may not be sufficient for 
the subsequent access. In situations for which a current level 20 
of trust (e.g., resulting from prior authentication of login 
credentials for an entity associated with the session) is 
sufficient for later access to the same or to another infor- 
mation resource, access is allowed without additional 
authentication. For example, in some security architectures 25 
in accordance with the present invention, the security archi- 
tecture proxies (204) the request to the requested informa- 
tion resource and streams (205) a resulting response back to 
the requesting client entity. 

As described elsewhere herein, sufficiency of current 30 
session credentials is determined using mapping rules that, 
in some realizations, include environment information. In 
general, current session credentials may be insufficient (1) 
because the identity of the requesting client has not yet been 
authenticated (e.g., in a first access situation), (2) because of 35 
a higher trust level requirement for the requested access, or 
(3) because of a change in mapping rules or environment 
that causes a previously sufficient credential no longer be 
sufficient for a particular trust level. Whatever the reason for 
the insufficiency, a request corresponding to a session and 40 
client entity that is insufficiently authenticated, and that is 
therefore not authorized, is passed to a facility for obtaining 
credentials of a type that, if authenticated, will support the 
required trust level. 

Typically, session credentials and/or an associated session 45 
token encode an expiration time (see description, above, of 
FIG. 4). In such configurations, a previously sufficient 
session credential is insufficient after its expiration. In some 
configurations, session credentials are periodically refreshed 
by reauthentication of the underlying login credentials. For 50 
example, in one implementation, a presented session token 
indicating expiration in less than five (5) minutes causes the 
security architecture to reauthenticate (not shown) underly- 
ing login credentials stored in a corresponding SessionOb- 
ject (e.g., under the private key of authentication component 55 
130). Reauthentication typically results in a new session 
credential and associated trust level Depending on then 
instant mapping rules, the associated trust level may or may 
not be sufficient. Also, reauthentication may fail if the login 
credentials have been invalidated, revoked or if the login 60 
credentials have expired. Assuming that reauthentication of 
login credentials is successful, updated session credentials 
are issued, for example, by authentication component 130 
and supplied (e.g., as a cookie encoded session token) to the 
client entity e.g., browser 170). 65 

Referring again to FIG. 2, a request corresponding to a 
session not authorized for a requested access is redirected 
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(206) to a credential gathering service (e.g., login compo- 
nent 120). The credential gathering service receives (207) 
the redirected access and obtains (208) a trust level require- 
ment for the requested access. In some configurations, the 
trust level requirement may be passed with the redirected 
access or otherwise associated with the redirected access, in 
others the trust level requirement may be re-obtained from 
an authorization service such as authorization component 
140. A trust level requirement is mapped (209) to at least one 
authentication scheme sufficient to achieve the requirement 
based on current trust level mappings and, if employed in the 
mapping rules, based on current environment information. 
Assuming that at least one authentication scheme is avail- 
able that, if successful, will support the required trust level, 
login credentials of that type are obtained (210) for the entity 
and authenticated (211). Some credential types (e.g., 
username/p ass word pairs, onetime passwords, enigma 
challenge, etc) may be obtained through an interactive 
process in which a principal (e.g., a human user) supplies the 
credentials) entry in an HTML form and POSTs form 
contents back to the credential gathering service. Others 
(e.g., certificates) may be obtained for the client entity from 
an agent or authority. For example, a personal digital cer- 
tificate (such as those issued by Verisign™, Thwate, Entrust 
or other certificate authority) may be obtained from a 
browser using an HTTP certificate request. In some 
configurations, a choice of credential types may be provided 
and user may select from a set of credential types sufficient 
for the requested access. Once appropriate login credentials 
have been obtained and authenticated, the session corre- 
sponding to the requested access is updated (213) to reflect 
the new authenticated session credentials. The now suffi- 
ciently authorized request is proxied (204) and results are 
streamed back (205) to the requesting client entity. Updated 
or refreshed session credentials are typically supplied as a 
session token (e.g., a cookie) encoded with the streamed 
results. 

FIG, 3 illustrates interactions between functional compo- 
nents in an exemplary functional decomposition of a secu- 
rity architecture. An on-line order processing transaction is 
exemplary and functional boundaries are merely illustrative. 
Based on the description herein, a wide variety of suitable 
enterprise information environments and functional decom- 
positions in accordance with the appended claims will be 
appreciated by persons of ordinary skill in the art. 

In the configuration of FIG. 3, application and central 
security portions (321 and 322, respectively) of the security 
architecture are illustrated. Of note, functional components 
of application security portion 321 are typically hosed as 
services on a first server environment, while functional 
components of central security portion 322 are hosted as 
services on a second server environment. In this way, most 
interactions amongst functional components occur within a 
single server environment and do not require network trans- 
actions. In the configuration of FIG. 3, credentials associated 
with a calling component (e.g., framework credentials asso- 
ciated with application security framework 303 or applica- 
tion credentials associated with order management service 
312) are used to establish sufficient authorization for net- 
work transactions. Other configurations may be employed, 
however, the relatively small number of network transac- 
tions (e.g., authentication transaction 331 and optional value 
passing transaction 332) tends to improve performance of 
the security architecture. Of note, authentication transaction 
331 need only be performed on login credential authentica- 
tion (e.g., at initial sign-on or credential upgrade) or reau- 
thenticated (e.g., to refresh session credentials). Value pass- 
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ing transaction 332 provides an optional facility for passing 
values amongst multiple components of a distributed appli- 
cation (e.g., a distributed implementation of order manage- 
ment service 312) wherein application credentials are used 
to mediate storage and retrieval of values in a central 
registry. 

User 301 interacts with browser 302 to place an order with 
order management service 312. An application security 
framework 303 receives an access request including the 
order and, operating in conjunction with a variety of other 
services, provides a single sign-on facility substantially as 
described above. If the order does not include a session 
token or cannot be otherwise associated with corresponding 
valid session credentials, then session credentials are 
obtained. As illustrated in FIG. 3, session credentials are 
obtained using login credentials (e.g., a username/password 
pair, a digital certificate, etc.) Typically, an access request 
without session credentials will not have associated login 
credentials. As a result, and default login credentials (e.g., 
identity= anonymous) are used during initial phases of a 
single sign-on process. Nonetheless, in some configurations, 
login credentials may be provided with an initial access 
request. More typically, an initial access request is received 
by application security framework 303 without session 
credentials or without prior presentation and authentication 
of login credentials sufficient to access the requested 
resource. In response to credential gathering operations, a 
subsequent request is made with login credentials that 
purport to be sufficient, if authenticated, to meet the trust 
level required for access to order management service 312. 
In such a case, session credentials are obtained by passing 
login credentials to a central security framework 304. 

Authorization of application security framework 303 for 
access to components of the central security portion 322 is 
checked by query to central authorization service 306. 
Assuming that framework credentials evidence sufficient 
authorization, login credentials are authenticated by central 
authentication service 307, Central authentication service 
307, in turn, interacts with central principal registry 310 to 
establish the identity and group membership of user 301 and 
with central session registry 311 to create a persistent 
session for subsequent accesses by user 301. Particulars of 
the request are logged to central audit service 308 and, if 
authentication was successful, session credentials are 
returned to application security framework 303. 

Signed session credentials are presented to application 
authorization service 313 together with an identifier for the 
requested resource and optionally with an identifier for a 
particular function or facility of the requested resource. In 
response, application authorization service 313 checks the 
authorization of the principal (e.g., of user 301) associated 
with the session credentials to access the requested resource. 
Application authorization service 313 interacts with appli- 
cation resource registry 314 to identify trust level require- 
ments for the requested resource (and in some 
configurations, for a particular function or facility of the 
requested resource) and determines the sufficiency of a 
current trust level evidenced by the session credential. Note 
that trust level is assessed by inspection of the session 
credential and without interaction with an authentication 
service. In some configurations (e.g., as illustrated in FIG. 
3), group membership is also evaluated as part of the 
authorization check. 

If the signed session credentials indicate that the request- 
ing entity, e.g., browser 302 on behalf of user 301, is 
sufficiently authorized to access order management service 
312, a CreateOrder request is passed to order management 
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service 312 and order processing proceeds in accordance 
with normal handling thereof. Additional accesses may be 
required, e.g., to select delivery options or to confirm some 
aspect of the order. Assuming that the additional accesses do 

5 not require a higher trust level, they will be passed to order 
management service 312 based on the correspondence of 
session credentials with trust level requirements. 

If an exception is thrown due to insufficient authorization, 
e.g., if the signed session credentials do not indicate that the 

10 requesting entity is sufficiently authorized to access order 
management service 312, a login credential gathering pro- 
cess is initiated. Based on the required trust level and on 
rules that encode the sufficiency of authentication schemes, 
a login credential is obtained from user 301 and/or browser 

15 302. The obtained login credential is of a type that, if 
authenticated, is sufficient to meet the trust level requirement 
for access to order management service 312. Aspects of an 
exemplary credential gathering process are described in 
greater detail above. However, as an example, FIG. 3 

20 illustrates the obtaining of a username/password pair. Once 
login credentials are obtained, they are passed to central 
security framework 304 (as described above) for authenti- 
cation by central authentication service 307 so that session 
credentials can be obtained, the requested access can be 

25 authorized, and the order processing initiated. Signed ses- 
sion credentials, typically embodied as a cryptographically 
secured session token that may be stored as a cookie, are 
passed back to browser 302 with results of the requested 
access. In this way, subsequent access requests are identified 

30 as part of a session and authorization may be quickly 
confirmed without unnecessary re-authentication. 

Exemplary Implementations 

35 In an exemplary embodiment, at least some of the above - 
described components are implemented as servlets execut- 
able in the context of a commercially-available web server 
environment. For example, the Java™ Embedded Server 
(JES) architecture with extensions for certificate handling, 

40 HyperText Transfer Protocol (HTTP), Simple Network 
Management Protocol (SNMP), Secure Sockets Layer 
(SSL), extensible Markup Language (XML) grammar pro- 
cessing and security Access Control list (ACL) support 
available from Sun Microsystems, Inc. is one suitable envi- 

45 ronment. Java and all Java-based marks and logos are 
trademarks or registered trademarks of Sun Microsystems, 
Inc. in the United States and other countries. 

In general, the description herein is focused on aspects of 
a security architecture, rather than on peculiarities of :a 

50 particular implementation environment. It is envisioned that 
security architectures in accordance with the teachings of the 
present invention may be implemented in the context of 
many commercially-available networked information ser- 
vice environments, including web server environments, as 

55 well as in custom environments and environments that in the 
future will be developed. However, to facilitate an under- 
standing of broad concepts using a specific exemplary 
environment, and without limitation, the description herein 
may include terminology specific to the Java Embedded 

60 Server (JES) architecture. Nonetheless, based on this 
description, persons of ordinary skill in the art will appre- 
ciate implementations suitable for other environments. The 
scope of the invention, as defined by the claims that follow, 
is not limited to any specific implementation environment. 

65 While the invention has been described with reference to 
various embodiments, it will be understood that these 
embodiments are illustrative and that the scope of the 
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invention is not limited to them. Many variations, 
modifications, additions, and improvements are possible. 
For example, the set of authentication schemes described 
herein is illustrative and embodiments in accordance with 
the present invention may include others, including those 
that may be hereafter developed. If employed, rules mapping 
trust levels to authentication schemes may be encoded in a 
variety of ways depending on the particular implementation. 
In general, such mapping rules may be encoded as static or 
dynamic table associating trust level to authentication 
schemes. Alternatively, mapping rules may be encoded as 
predicates or in other declarative forms. Mapping rules may 
be encoded in a weighted logic or fuzzy set form. 
Additionally, particular mappings may depend environment 
information. Furthermore, evaluation of mapping rules may 
be performed in a variety of functional components such as 15 
an authorization service, a credential gathering service or a 
gatekeeper. Session continuity may be provided using cryp- 
tographically secure session tokens passed as cookies or by 
other mechanisms. 

In some configurations, a session token is a compact 20 
encrypted representation of at least selected contents of a 
session credential. Other compact representations corre- 
sponding to a session credential may be employed. 
Alternatively, the same representation of session credentials 
may be employed both within the security architecture and 25 
outside the security architecture (e.g., at a browser or other 
client). Suitable contents of a session credential (and session 
token, if employed) will be appreciated by persons of 
ordinary skill in the art based on the description herein of 
specific examples. 30 

More generally, plural instances may be provided for 
components described herein as a single instance. Finally, 
boundaries between various components, services, servlets, 
registries and frameworks are somewhat arbitrary, and par- 
ticular operations are illustrated in the context of specific 
illustrative configurations. Other allocations of functionality 
are envisioned and may fall within the scope of claims that 
follow. Structures and functionality presented as discrete 
components in the exemplary embodiments) may be imple- 
mented as a combined structure or component. These and 
other variations, modifications, additions, and improve- 
ments may fall within the scope of the invention as defined 
in the claims that follow. 

What is claimed is: 

1. A session credential for use in a security architecture 
controlling access to one or more information resources, the 
session credential comprising: 

a principal identifier uniquely identifying a principal; and 
an encoding of authorization accorded by the security 
architecture after prior authentication of a login cre- 
dential corresponding to the principal, 
the principal identifier and authorization encoding being 
cryptographically secured and allowing the security 
architecture to evaluate sufficiency of the authorization 
for access to the one or more information resources 
without re-authentication of the login credentials. 

2. A session credential as in claim 1, 
wherein the cryptographic securing includes encryption 

of at least the principal identifier and authorization 
encoding using a private key associated with the secu- 
rity architecture. 

3. A session credential as in claim 1, further comprising: 
an encrypted portion and an unencrypted portion; 
the unencrypted portion allowing contents of the session 

credential, including the principal identifier and autho- 
rization encoding, to be read without possession of a 
key; 
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the encrypted portion being encrypted with a private key 
associated with the security architecture and allowing 
authenticity of the unencrypted portion to be confirmed 
using a public key corresponding to the private key. 

4. A session credential as in claim 3, 
wherein the encrypted portion is supplied external to the 

security architecture as a session token that uniquely 
identifies a corresponding persistent session maintained 
by the security architecture. 

5. A session credential as in claim 4, 
wherein the session token is encoded as a cookie supplied 

to a browser; and 
wherein the cookie is included with access requests made 
by the browser targeting the one or more information 
resources. 

6. A session credential as in claim 3, 
wherein the cryptographic securing is by a private key 

possessed substantially only by an authentication com- 
ponent of the security architecture; and 
wherein authenticity of the cryptographically secured 
principal identifier and authorization encoding is veri- 
fiable by components other than the authentication 
component using a public key corresponding to the 
private key. 

7. A session credential as in claim 1, 
wherein the cryptographic securing includes a digital 

signature encompassing at least the principal identifier 
and authorization encoding and thereby allows authen- 
ticity of the principal identifier and authorization 
encoding to be confirmed using a public key. 

8. A session credential as in claim 1, further comprising: 
an expiration encoding. 

9. A session credential as in claim 1, further comprising: 
a session identifier. 

10. A session credential as in claim 1, further comprising: 
a group identifier. 

11. A session credential as in claim 1, further comprising: 
one or more additional elements selected from an expi- 
ration encoding; a session identifier; and a group 
identifier, 

the one or more additional elements also cryptographi- 
cally secured. 

12. A session token for transfer between a client entity 
operating on behalf of a principal and a security architecture 
controlling access to an information resource, the session 
token comprising: 

a principal identifier uniquely identifying the principal; 
and 

an indication of authorization level accorded by the 
security architecture after prior authentication of a 
login credential corresponding to the principal, 
the principal identifier and authorization level indication 
being cryptographically secured and allowing the secu- 
rity architecture to evaluate sufficiency of the authori- 
zation for access to the information resource without 
re -authentication of the login credentials. 

13. A session token as in claim 12, encoded as a cookie 
stored at a browser. 

14. A session token as in claim 12, placed at a browser in 
response to a set cookie directive by the security architec- 
ture. 

15. A session token as in claim L2, encoded for transfer to 
the client entity. 

16. A session token as in claim 12, encoded in a commu- 
nication medium as information in transit between the client 
entity and the security architecture. 
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17. A session token as in claim 12, 

wherein the client entity includes a browser; and 
wherein the session token is embodied as a cookie sup- 
plied to the browser by the security architecture and 
included with an access request made by the browser 5 
targeting the information resource. 

18. A method of providing authorization verification in a 
security architecture controlling access to one or more 
information resources, the method comprising: 

obtaining a login credential and authenticating a principal 10 
thereby; 

issuing a cryptographic ally secured session credential 
encoding at least an identifier for the principal and a 
first authorization accorded based on the authenticat- 
ing; and 

for plural requests for accesses to the one or more of the 
information resources, selectively allowing access 
based on sufficiency of the first authorization encoded 
by the cryptographically secured session credential for 2 o 
access to the one or more of the information resources, 
wherein the selective allowing is performed without 
additional login credential authenticating. 

19. A method as in claim 18, further comprising: 
digitally signing the session credential prior to issuance 25 

thereof; and 

prior to the selective allowing, verifying authenticity of 
the principal identifier and first authorization encoding 
using a public key. 

20. A method as in claim 18, further comprising: 30 
encrypting at least the identifier for the principal and the 

first authorization using a private key, 
the issued cryptographically secured session credential 
including at least the identifier for the principal and the 
first authorization in both encrypted and free text form; 35 
and 

prior to the selective allowing, verifying authenticity of 
the principal identifier and first authorization encoding 
using a public key corresponding to the private key. 

21. A method as in claim 20, further comprising: 40 
supplying the encrypted form of at least the identifier for 

the principal and the first authorization to a client entity 
external to the security architecture as a session token; 
the client entity presenting the session token with subse- 45 
quent access requests so that the security architecture 
may perform the selective allowing of the subsequent 
access requests without additional login credential 
authenticating. 

22. A method as in claim 21, 5Q 
wherein the client entity includes a browser; and 
wherein the session token is encoded as a cookie. 

23. A method as in claim 18, further comprising: 

on an access request for which the first authorization 
encoded by the cryptographically secured session ere- 55 
dential is insufficient, obtaining a second login creden- 
tial and authenticating the principal thereby: 
issuing a second cryptographically secured session 
credential encoding a second authorization accorded 
based on the authenticating by the second login 60 
credential; and 
selectively allowing the access request based on suffi- 
ciency of the second authorization encoded by the 
second cryptographically secured session credential. 

24. A method as in claim 18, 65 
wherein the cryptographically secured session credential 

also encodes an expiration; 
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the method further comprising: 

prior to the expiration, reauthenticating the principal by 
the first login credential; 

issuing a third cryptographically secured session cre- 
dential encoding a third authorization accorded 
based on the authenticating by the first login creden- 
tial; and 

selectively allowing subsequent access requests based 
on sufficiency of the third authorization encoded by 
the third cryptographically secured session creden- 
tial. 

25. A method as in claim 24, 

wherein the first and third authorizations are equivalent. 

26. A method as in claim 24, 

wherein the first and third authorization are encoded as 
trust levels that differ in accordance with either or both 
of a changed session environment and changed map- 
pings of credential types to trust levels. 

27. A method as in claim 18, 

wherein the login credential is selected from a set of 
credential types including one or more of a username 
password pair, digital certificate, an encrypted creden- 
tials based on asymmetric, symmetric, public, private, 
or secret key technology, a one-time password, a bio- 
metric credential based on retinal scan, voice print, or 
finger print, and a possession based credential embod- 
ied in a smart card, Enigma card or physical key. 

28. A method as in claim 18, embodied as one or more 
computer program products including functionally descrip- 
tive information for directing a processor to perform the 
login credential obtaining and principal authenticating, the 
cryptographically secured session credential issuing, and the 
selectively allowing access based on sufficiency of the first 
authorization by the cryptographically secured session 
credential, the one or more computer program products 
encoded by or transmitted in at least one computer readable 
medium selected from the set of a disk, tape or other 
magnetic, optical, or electronic storage medium and a 
network, wireline, wireless or other communications 
medium. 

29. An information access control facility comprising: 
an application proxy for receiving an access request 

targeting one of a set of information resources, extract- 
ing a cryptographically secured session token from the 
access request, and selectively proxying the access 
request; 

means responsive to the application proxy for evaluating 
sufficiency of an authorization encoded in the crypto- 
graphically secured session token for access to the 
targeted information resource. 

30. An access control facility as in claim 29, further 
comprising: 

credential gathering means responsive to an insufficient 
zero or more login credentials associated with the 
session, the credential gathering means obtaining a 
login credential of type sufficient, if authenticated, to 
achieve a trust level requirement of the targeted infor- 
mation; and 

authentication means for receiving the obtained login 
credential, authenticating a principal thereby and issu- 
ing a session credential corresponding to the session 
token. 

31. An access control facility as in claim 29, further 
comprising: 

means for transferring the session token between the 
access control facility and the client entity. 
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32. An access control facility as in claim 29, embodied as medium and a network, wireline, wireless or other commu- 
a computer program product encoded by or transmitted in at nications medium, 
least one computer readable medium selected from the set of 

a disk, tape or other magnetic, optical, or electronic storage ***** 
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